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Communication mechanism for calls in which speaking is not 
possible 

BACKGROUND of the invention 

The invention relates to methods and equipment for implementing a 
5 communication mechanism for calls in which speaking is not possible. 

There are several situations in which one or both parties of a call 
cannot speak on a telephone. For instance, libraries, restaurants and public 
performances (concerts, theatres, movies, etc.) are situations in which speak- 
ing on a telephone is prohibited or socially unacceptable. If the called party (B) 
10 cannot take a call, the calling party (A) is usually directed to voice mail. Alter- 
natively, the parties may communicate via short messages. Short message 
service, like the one provided by the GSM system and its derivatives, provides 
a widely-used substitute for conventional calls if one or both parties cannot 
speak on a telephone. But the short message service has its share of prob- 
15 lems. For instance, reading and sending each message requires several acts 
via the telephone's menu system. 

BRIEF DESCRIPTION OF THE INVENTION 

An object of the present invention is to provide improved methods 
and equipment for calls in which two-way speech is not possible. 
20 The object of the invention is achieved by the methods and equip- 

ment which are characterized by what is stated in the independent claims. The 
preferred embodiments of the invention are disclosed in the dependent claims. 

For example, the invention can be implemented as a method for 
processing a voice call establishment request from a calling terminal to a 
25 called terminal. A conventional method comprises detecting the call establish- 
ment request, alerting the called terminal or its user and setting up a two-way 
connection between the calling and the called terminals. A method according 
to the invention also comprises the following steps: 

determining that a two-way voice call between the calling terminal 
30 and the called terminal is not allowed; 

receiving silent messages via the called and/or calling terminal's 
user interface; and 

conveying information based on said silent messages to the calling 
and/or called terminal, respectively. 
35 An aspect of the invention is a method for processing a call setup 
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request from an A party to a B party. Another aspect of the invention is an ap- 
paratus, such as a mode server, for supporting or implementing the above 
method. The mode server can be located in a network element or in the called 
terminal or both. As used herein, the mode server is an entity that determines 

5 or affects the mode of the call in the incoming and/or outgoing direction. An 
illustrative but non-exhaustive list of call modes comprises normal speaking, 
messaging, chatting and limited chatting. Speaking is the preferred mode for 
calls between two persons, but there are situations in which speaking is not 
allowed. As far as the invention is concerned, the precise reason as to why 

0 speaking is not allowed does not matter. Speaking may be prohibited by law or 
etiquette, or the called party may wish to avoid being overheard. From the 
point of view of the equipment, the called party gives an indication that speak- 
ing is not allowed. Such an indication may be given before alerting the called 
party, in which case the indication is a "current profile" or part of it. Or, indica- 
5 tion may be given after the alert, in which case the called party selects the call 
mode on a case-by-case basis. What matters is that at least one party cannot 
participate in a two-way voice call and must participate silently instead. Yet 
further, the need to establish a silent call, in at least one direction, may develop 
during the call. For instance, one of the parties may be in a movie, and it may 

20 be possible to speak before the movie starts, but when it starts, the call must 
be continued silently, if at all. However, changing the call mode during a call 
may be technically simpler than having a silent call from the beginning, be- 
cause the parties can inform each other on the situation. 

In the context of this invention, the attribute "silent" means a call 

25 mode in which the party in question does not speak. Such a call mode could 
also be called a "non-voice" call. For example, if the B party is in a library, 
he/she can have a call in which the incoming half-call is a conventional voice 
call but the outgoing half-call is a silent one. On the other hand, a hearing- 
impaired person may participate in a call in which the incoming half-call is si- 

30 lent but the outgoing one is a conventional voice call, assuming that the hear- 
ing-impaired person is able to speak. 

An example of a silent call mode is chatting. Chatting means a 
mode of conversation in which the chatting party sends his/her messages by 
typing on the terminal's keyboard or keypad. Obviously, sending arbitrary mes- 

35 sages by chatting requires the ability to see the terminal's display and key- 
board/keypad, and this is impossible in many public performances. But even in 
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such situations a party can participate in a two-way dialogue by limited chat- 
ting. Limited chatting is a mode of conversation in which a limited number of 
messages are available. For example, a terminal's user interface may offer two 
keys for "yes" and "no", and optionally, a third key for "I don't understand" (or "I 

5 cannot answer right now"). Instead of the few dedicated keys, or in addition to 
them, there may be a few different key presses. For example, a single click, a 
double click and a long press may mean three different things. A combination 
of three keys and three different key presses provides nine different messages 
such that the terminal user does not have to move his/her fingers or see the 

10 terminal. Alternatively, or in addition to the different keys/key presses, the ter- 
minal may store several pre-stored responses of which one is selected. The 
terminal's user interface may provide next/previous selection keys and an OK 
key. Whenever, the next/previous keys are used, a next or previous message 
may be displayed or read out to the terminal user via an earphone, and the 

15 message is only sent to the other party when the user selects the message 
with the OK key. 

A server, as in the context of "mode server", is something that pro- 
vides a service. The mode .server may be a separate server or an attachment 
to pre-existing call processing equipment, such as a mobile switching centre or 

20 private branch exchange. Or, the mode server may be implemented as a soft- 
ware agent in the user equipment, such as a mobile telephone. As a further 
alternative, the mode server may be implemented as a distributed collection of 
software, such as a client/server system. 

The invention is based on the idea of processing the two directions 

25 (or "half-calls") of the call, ie from A to B and B to A, separately. An example of 
such separate processing is that if B is unable to speak, the direction from A to 
B is processed as a conventional voice call but the inverse direction from B to 
A is processed as a chat connection. 

This separate processing does not mean that the directions of the 

30 call are always processed differently. For example, it is possible to process 
both directions as chat connections. But even such a two-way chat connection 
is different from a conventional exchange of short messages because each 
message of the chat connection does not have to be addressed separately. 
The present invention also differs from the conventional short message service 

35 in that the caller attempts to initiate a normal voice call but the mode server 
automatically determines that the voice call is not permitted and changes the 
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call mode to silent, at least in one direction. 

The invention brings about certain problems or questions that do not 
exist in conventional call processing systems. These problems or questions 
are related to the fact that a call may be first attempted as a conventional call 

5 but if either party is unable to speak, at least one call direction must be proc- 
essed as silent. For instance, which element determines which calls are proc- 
essed as silent? How is this determination made? Various preferred embodi- 
ments of the invention provide solutions to these problems. 

One solution to the above residual problems is as follows. The mo- 

10 bile phone's user interface provides two (or more) different techniques to an- 
swer an incoming call. For instance, the user interface may have buttons for 
"normal call" and "silent call". Alternatively, a single short click on an "answer" 
button results in a normal call whereas a double click or a long press on the 
same button results in a silent call. In this embodiment, the mobile terminal 

15 user provides the input that lets the mobile telephone (or the underlying net- 
work) to determine the call mode on a per-call basis. 

An alternative solution to the above residual problems is based on 
user profiles. Before entering a location in which speaking on a telephone Is 
prohibited or unacceptable, the terminal user changes his/her profile to one 

20 that indicates silent calls. The profile may be maintained in the terminal or in an 
appropriate network element. Co-assigned Finnish patent application 
20021664, filed 18 September 2002, titled "User-configurable call answer- 
ing/redirection mechanism", discloses various techniques for maintaining user 
profiles. That patent application is not public at the filing date of the present 

25 invention, and its relevant parts are repeated later in this specification. 

BRIEF DESCRIPTION OF THE DRAWINGS 

In the following the invention will be described in greater detail by 
means of preferred embodiments with reference to the attached drawings, in 
which: 

30 Figures 1 A and 1B show examples of network architectures in which 

the invention can be used; 

Figure 2 shows the major functional blocks of a mode server ac- 
cording to a preferred embodiment of the invention; 

Figure 3 is a flow chart illustrating mode-related decisions at the 
35 time of answering a call; 



WO 2004/028124 ^PCT/FI2003/000032 



5 

Figure 4 shows a mobile terminal's user interface that has been 
specially adapted to select a special call mode; 

Figure 5A shows a signalling diagram for a two-way chat connec- 
tion; 

5 Figure 5B shows a signalling diagram for an asymmetric voice/chat 

connection; 

Figure 6 shows a user interface for selecting one of a number of 
predetermined responses (messages); 

Figure 7 illustrates user records and caller groups; 
10 Figure 8 illustrates reachability profiles; 

Figure 9 illustrates redirection settings; 

Figure 10 illustrates associations of caller groups, reachability pro- 
files and redirection settings; and 

Figure 1 1 is a flow chart illustrating the operation of a reachability 

15 server. 

DETAILED DESCRIPTION OF THE INVENTION 

Figures 1 A and 1B show examples of network architectures in which 
the invention can be used. Figure 1 A shows an example of a network architec- 
tures in which the mode server is located in the access network serving the 

20 subscribers. Reference sign TE generally denotes user terminals 101 and 102, 
of which terminal 101 is used by the calling party A and terminal 102 is used by 
the called party B. The terminals 101 , 102 are connected to an access network 
AN. The access network AN can use any network technology capable of proc- 
essing calls, including but not limited to GSM, UMTS or WLAN with VoIP. The 

25 access network AN has base stations BS to provide a radio interface to user 
terminals 101, 111. One or more switching elements SW route calls, via differ- 
ent base stations, to different terminals. For example, in a GSM network, the 
switching elements are mobile services switching centres (MSC). A Home Lo- 
cation Register HLR stores subscriber data. An answering server AS provides 

30 voice mail services when Bill is unable to receive calls. 

The access network AN is connected to other networks via one or 
more gateway elements GW. For example, the other networks may be a Public 
Switched Telephone Network PSTN and/or a data network DN, such as the 
Internet and/or its closed subnetworks, commonly called intranets or extranets. 

35 The elements of Figures 1A and 1B described above are or can be entirely 
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conventional. In addition to the conventional elements, the network architec- 
ture comprises a mode service function. In the example shown in Figure 1A, 
the mode service function is implemented as a mode server MS that is closely 
coupled to the switching element SW. The internal structure of an exemplary 

5 embodiment of the mode server MS will be shown in Figure 2. 

Figure 1B shows an embodiment of a network architecture in which 
the mode server, here denoted by MS', is located in the called user's terminal 
102. The two placements for the mode server, namely in the access network 
AN and in the terminal 102, need not be mutually exclusive, however, and an 

10 optimal implementation of the mode service is achieved by a combination of a 
centralized mode server MS and terminal-based mode server MS'. For exam- 
ple, terminals capable of multimedia operations have sufficient memory for act- 
ing as a voice storage for incoming and/outgoing voice messages, and/or as a 
speech synthesizer. An advantage of a voice mail box in a terminal is that the 

15 terminal can inform the caller that the call cannot be answered and store a 
voice message from the caller, without disturbing people near the terminal. A 
terminal-provided voice mail box is independent from the current access net- 
work operator. Voice storage for incoming voice messages provides the termi- 
nal with answering machine capability. In other words, the terminal has an in- 

20 tegrated voice mail box that is independent of the access network. Voice stor- 
age for outgoing voice messages enables the terminal user to select and send 
one of several pre-stored voice messages to the other party. In other words, 
the terminal user needs only a few keys to respond by voice, without speaking 
on the telephone. Similar functionality is provided by a speech synthesizer in- 

25 tegrated in the terminal. 

Figure 2 shows the major functional blocks of a mode server 
according to a preferred embodiment of the invention. If the mode server is a 
network-based mode server MS shown in Figure 1 A, it is preferably installed in 
the switching element SW. On the other hand, if the mode server is a terminal- 

30 based mode server MS 1 shown in Figure 1B, it is installed in the terminal TE 
(shown as terminal 102 in Figure 1B). 

An essential functional block of the mode server MS, MS' is a mode 
converter MC that is capable of changing the call mode from a voice call to one 
or more variants of non-voice calls, such as chatting, limited chatting, trans- 

35 mission of pre-stored or synthesized voice, etc. 
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According to a preferred embodiment of the invention, the mode 
server MS comprises a reachability server RS and an associated database 
DB. The database DB stores profile records PR that indicate the current profile 
of the called subscriber. If the mode server MS' is located in the called party's 

5 terminal, a single current profile is sufficient, and the subscriber information is 
redundant. Further preferred embodiments of the reachability server RS and 
the profiles will be described in connection with Figures 7 through 1 1 . As far as 
the invention in its broadest sense is concerned, it is not strictly necessary to 
store any profiles, as long as the called party explicitly indicates a desired call 

10 mode each time he/she answers an incoming call. A stored profile PR is bene- 
ficial, however, because it provides the mode server with a default mode for 
the incoming call, and enables the mode server to direct the incoming call to 
an answering service when the called party is unable to take any calls, includ- 
ing silent ones. 

15 Figure 3 is a flow chart illustrating a preferred embodiment for 

mode-related decisions at the time of answering a call. This embodiment 
shows how pre-stored profiles and on-the-fly decisions can both be used to 
determine an appropriate mode for an incoming call. In step 3-2, the mode 
server MS checks whether the called party's profile, if any, indicates voice 

20 mail, that is, an answering service. If yes, the call is directed to voice mail in 
step 3-8. If the profile does not indicate voice mail, or none exists, the user is 
alerted in step 3-4. If the current profile indicates silent calls, the user is alerted 
silently, preferably by a vibrating alert. In step 3-6, the mode server MS checks 
whether the called party responds in a predetermined time, such as 10 sec- 

25 onds. If not, the call is directed to voice mail in step 3-8. If the user does re- 
spond, the process advances to step 3-10 in which the mode server MS 
checks whether the called party selects an explicit call mode when responding 
to the alert. Techniques for on-the-fly indication of a call mode will be de- 
scribed in connection with Figure 4. If the called party selects an explicit call 

30 mode, the call is processed in the user-selected mode in step 3-12. Otherwise 
the process advances to step 3-14 in which the mode server MS checks if 
there is a profile that indicates a certain call mode. If yes, the call is processed 
in the mode indicated by the profile in step 3-16. 

The embodiment shown in Figure 3 is beneficial in the sense that 

35 the user can select a profile that indicates a default mode for incoming calls. 
However, the user may override that default on a per-call basis. It should be 
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noted, however, that the flow chart shown in Figure 3 is only an illustrative ex- 
ample, and the different checks may be performed in other orders as well. 

Figure 4 shows a mobile terminal's user interface Ul that has been 
specially adapted to select a special call mode. The user interface Ul com- 

5 prises a display Dl that indicates the calling party. The user interface Ul also 
comprises a set of function keys 41 that allow the user to respond with a de- 
sired call mode. The function keys 41 may be supported by associated legends 
42. In this example, the function keys 41 comprise keys for a normal call and 
chatting. The function keys 41 may be implemented in a variety of ways. For 

10 instance, there may be up/down/ok keys or a joystick-type switch. Or, the set 
of function keys 41 may be replaced by a roller that is rolled upwards or down- 
wards and clicked for selecting the current call mode. 

Figure 5A shows a signalling diagram for a two-way chat connec- 
tion. This signalling diagram relates to an embodiment in which a network- 

15 based mode server MS comprises (or is otherwise associated with) a mode 
converter MC, a reachability server RS and its associated database DB. In 
step 5-0, the calling terminal A sends a call setup signal which proceeds to the 
switching element SW. In step 5-2, the switching element SW makes an in- 
quiry to the reachability server RS (which in turn makes an inquiry to its data- 

20 base DB) concerning the called party's current profile. In step 5-4, the reach- 
ability server RS/database DB return the current profile to the switching ele- 
ment SW. Let us assume that the current profile indicates a call mode of 
"chat". In step 5-6, the switching element SW conveys the call setup signal to 
the terminal of the called party B. In step 5-8, the B party responds. Now the 

25 switching element SW knows that the B party is able to take the call. For ex- 
ample, the B party may be located in a place where speaking or voice alert are 
prohibited but the B party is able to take the call because the terminal's alert is 
set to silent/vibrating. In step 5-10, the switching element SW requests the 
mode converter MC to read instructions to the calling party A. In step 5-12, the 

30 mode converter MC reads a voice announcement that tells the caller A that B 
can hear A's voice but can only respond by chatting. The voice announcement 
is preferably read to the B party as well. Otherwise, B could be confused be- 
cause he/she does not hear anything as long as A listens to the voice 
announcement. In step 5-14 there is a two-way chat connection between A 

35 and B. 
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Figure 5B shows a signalling diagram for an asymmetric voice/chat 
connection. This means that A communicates by voice and B responds by 
chatting. Steps 5-0 through 5-12 are similar to the corresponding steps in Fig- 
ure 5A and will not be described again. However, Figure 5B shows a scenario 
5 in which A can keep talking for the entire duration of the connection, and the 
contents of the announcement in step 5-12 are adapted accordingly. In step 
5-22, A talks to B who may hear A's speech via an earphone connected to the 
terminal. In step 5-24, B responds by chatting (typing text). In step 5-26, B's 
text response is converted to speech. For example, the mode converter MC 
10 may comprise a speech synthesizer for converting chat responses to speech. 
Alternatively, the mode converter MC may store a number of pre-recorded 
voice responses of which the B party selects one. This means that the signal in 
step 5-24 is a selection of one of the pre-recorded voice responses. A pre- 
ferred embodiment of the mode converter MC supports both options, ie, syn- 
15 thesized speech and pre-recorded voice responses. A benefit of synthesized 
speech is that an arbitrary response can be sent. In other words, the re- 
sponses do not have to be pre-recorded. On the other hand, it is beneficial to 
be able to store certain frequently-used responses as pre-recorded voice re- 
sponses, because it is faster to select one of pre-recorded voice responses 
20 than to type the response from scratch. Also, if the B party is in a theatre or the 
like, even chatting may be impossible, and the only way for the B party to 
communicate bi-directionally is to select one of pre-recorded messages. In 
step 5-28, the B party's response is finally conveyed to the A party. 

In the example shown in Figure 5B, the mode converter MC per- 
25 forms text-to-speech conversion. If the mode converter MC comprises a 
speech-recognition apparatus, it is also possible to perform speech-to-text 
conversion. This means, for example, that the parties can have a two-way 
communication in which one party speaks and listens while the other party 
communicates by chatting. Naturally, current speech-to-text conversion is not 
30 yet mature enough to support continuous speech from an arbitrary caller in 
arbitrary surroundings, but speech-to-text conversion is possible with limited 
vocabulary and small pauses between words. 

Figure 6 shows a user interface for selecting one of a number of 
predetermined messages. This embodiment eliminates the need to type fre- 
35 quently-used responses key by key. In the example shown in Figure 6, the 
terminal's user interface Ul comprises programmable function keys 61 that are 
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preferably associated with adaptive legends 62. The user uses the function 
keys 61 to select a desired response from a list of several pre-stored mes- 
sages 63. In this example, the user is about to select the phrase "I will call you 
later", denoted by reference numeral 64. 

5 The terminal shown in Figure 6 has the capability to store the pre- 

recorded messages 63. The act of storing pre-recorded messages is techni- 
cally similar to editing a terminal's address book and needs no detailed de- 
scription. One way to use the pre-stored messages is such that a speech syn- 
thesizer converts a text message to synthesized speech. Another possibility is 

10 that the pre-stored messages are pre-recorded audio messages, in which case 
the terminal user can respond with his/her own voice. The act of storing pre- 
recorded audio messages is technically similar to recording user voices in 
voice dialling and needs no detailed description. 

The user interface Ul shown in Figure 6 can be used even in dark- 

15 ness if the currently-selected message 64 (synthesized or pre-stored) is read 
out to the terminal user via the terminal's earphone, and only when the termi- 
nal user presses the OK button, the selected message 64 is transmitted to the 
other party. 

In the above description of the invention, a cursory reference was 
20 made to the use of profiles in connection with the mode server shown in Figure 
2. Figures 7 through 1 1 illustrate the use of profiles and redirection settings in 
more detail, in the context of further preferred embodiments of the invention. 

Within this detailed description, the name "Bill" refers to the terminal 
user whose incoming calls will be processed according to the invention. The 
25 reason for this name is that Bill will be acting the called or B party during a call, 
and "Bill" begins with a B. 

Figure 7 illustrates Bill's address book 70 and caller groups 73. As 
used herein, a caller group means a set or group of potential callers (future A 
parties) sharing similar redirection settings. A call group can comprise one or 
30 several members. The address book 70 is basically similar to the address book 
stored in a SIM card that is attached to a GSM mobile telephone. The address 
book contains a record for each of Bill's contacts (persons or companies). 
Each record comprises a name field 71 and a number (or address) field 72. 
The name field 71 contains a free-format name, as is well known from conven- 
35 tional GSM telephones. The number/address field 72 may contain a conven- 
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tional telephone number or any usable network address, such as an MSISDN 
number, TCP/IP address, e-mail address or the like. 

Reference numeral 73 generally denotes Bill's caller groups. In this 
example, the caller group "Family" consists of the records for Alice, Bob and 

5 Cecilia. Another caller group "Colleagues" consists of the records for Dave L, 
Eric M and Frank W. The third caller group "Secretary" only comprises Bill's 
secretary Gail T. The fourth caller group "Friends" comprises Harry P and Ian 
R. The four first caller groups are formed explicitly, such that Bill explicitly adds 
records 70 (potential callers) to one of the caller groups 73. 

10 In addition to explicit caller groups, there may be implicit caller 

groups, two of which are shown in Figure 7. In this example, a first implicit 
caller group "others" comprises all the records 70 in the terminal's address 
book that do not belong to any of the explicit caller groups. As soon as a re- 
cord 70 is added to one of the explicit caller groups, that record is removed 

15 from the "Others" group. The caller group "Others" may be used to indicate 
how to process calls from persons that are listed in Bill's address book 70 but 
do not belong to any of the explicit caller groups. Another implicit caller group 
"Unknown" comprises persons that are not stored in Bill's address book. The 
caller group "Unknown" may be used to indicate how to process calls from per- 

20 sons that are not known to the called party. 

As regards the association of the records 70 and caller groups 73, 
what really matters to the reachability server/service is the association of a 
number/address field 72 and a caller group 73. This is because the reachability 
server detects the caller's identity based on the caller's number (or other net- 

25 work address) 72. For the reachability server (and call processing in general), 
the name 71 is irrelevant. From Bill's point of view, however, it is much more 
convenient to associate a caller group 73 to a name 71 than to a number 72. 

Figure 8 illustrates reachability profiles 80. If the profiles 80 are 
stored in a centralized (network-based) mode server, the profiles have to be 

30 associated with a certain subscriber, such as the profile PR shown in Figure 2. 
In Figure 8, we assume that the profiles 80 are stored in a terminal-based 
mode server, or that the profiles are associated with a certain subscriber, al- 
though such association is not shown. 

Each reachability profile 80 comprises at least a label (or identifier) 

35 field 81 . According to a further preferred embodiment of the invention, a reach- 
ability profile 80 may also comprise a free-format presence information field 82. 
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For example, the reachability profile "Meeting" comprises a presence informa- 
tion field 82 whose contents is "I am in a meeting..." This presence information 
may be returned to a caller if the called party cannot answer calls. 

According to another preferred embodiment of the invention, a 

5 reachability profile 80 may also comprise a default redirection setting field 83. 
The use of redirection settings will be explained in connection with Figure 9. 

Figure 9 illustrates Bill's redirection settings 90. A redirection setting 
is a parameter that is used to answer the following question: what to do with a 
call setup request? The redirection setting indicates one or both of the follow- 

10 ing: 1) where (and whether) the call is redirected, and 2) which mode the call is 
changed into. An example of the first alternative is a setting which determines 
that an incoming call is to be redirected to a different number (or another net- 
work address). For example, a redirection setting may indicate that a call is 
first attempted to the B party's user terminal for five seconds, then to a home 

15 number for 10 seconds and then to an answering service. Alternatively, a call 
may be routed to an Internet address, either temporarily or during waiting. An 
example of the second alternative is a setting which determines that the call 
mode of an incoming call is changed to chat. In other words, if a voice call 
cannot be established, a chat connection may be set up instead. Thus the redi- 

20 rection setting may include a call mode indicator that indicates a changed call 
mode. For example, the changed call mode may indicate a silent communica- 
tion for one or both of the parties. 

Each redirection settings record 90 consists of a label (or identifier) 
field 91 and an actual redirection setting field 92. The label/identifier field 91 is 

25 preferably a free-format field, whereby Bill can enter short but descriptive 
names. From the point of view of the reachability server, however, any identi- 
fier is usable. The first redirection settings record 901 has a label field 91 of 
"OfficeFirst" and a redirection setting field 92 of u 5sOffice# / 5sMobile# / An- 
swer*". Herein, "Office#" stands for Bill's office telephone number, Mobile# 

30 stands for his mobile terminal number and Answer# stands for the number of 
the answering service (voice mail). The redirection setting field 92 of "5sOffice# 
/ 5sMobile# / Answer#" is interpreted so that a call to the office number is at- 
tempted first for five seconds, then the mobile terminal's number is attempted 
for another five seconds, and if that fails too, the call is redirected to the an- 

35 swering service. The next two records 902 and 903 are self-explanatory based 
on the previous example. The fourth redirection settings record 904 means that 
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an incoming call will be redirected to the telephone of Bill's secretary. Records 
905 and 906 indicate that a caller is redirected to URL addresses www.addr1.fi 
and www.addr2.fi, respectively. For instance, www.addr1.fi may be the ad- 
dress of a web page informing the caller that the terminal user is unable to re- 

5 ceive calls, and www.addr2.fi may be the address of a more informative web 
page for more trusted callers. 

Instead of a different number or network address, or in addition to it, 
the redirection setting field 92 may indicate a change of call mode. For in- 
stance, Bill may be in a library in which it is socially unacceptable to speak on 

10 the telephone but Bill may be able to chat via the telephone's keyboard or key- 
pad. According to a further preferred embodiment, the call mode is processed 
separately for each half-call or direction of call, that is, for the incoming and 
outgoing directions. For instance, when eating in the restaurant, Bill may not 
be able to speak on the telephone but may be able to listen to the caller's 

15 voice and respond via a chat connection. 

In the example shown in Figure 9, the ">" and "<" signs mean 
change of call mode in the incoming and outgoing directions, respectively. For 
instance, redirection settings record 907, labelled "Chat", has a redirection set- 
ting of ">Chat<Chat" which means that both the incoming and outgoing half- 

20 calls are converted to chat mode. The next record 908, labelled "Voice/Chat", 
has a redirection setting of "<Chat" which means that only the outgoing half- 
call is converted to chat mode. 

The last record 909, labelled "Voice/2KeyChat", has a redirection 
setting of "<2KeyChat" which means that the outgoing half-call is converted to 

25 2-key chat mode. The 2-key chat mode in the outgoing direction means that 
the mobile terminal user is able to listen to the caller's voice but is only able to 
respond with a very small number of keys, such as two or three. The two keys 
can be "yes" and "no". An optional third key may mean "I don't 
know/understand". The 2- (or 3-) key chat mode is useful in a situation where 

30 even conventional chatting is impossible. For instance, Bill may be in a con- 
cert, and calls from most caller groups are redirected to voice mail but calls 
from a babysitter are converted to 2-key chat mode. The babysitter, who may 
be facing an urgent problem, calls Bill. The alert of Bill's terminal is set to silent 
but vibrating. As soon as Bill feels the vibrating alert, he can place an ear- 

35 phone to his ear and take the call. The babysitter may then describe the situa- 
tion and ask questions that can be answered by "yes" and "no" keys which Bill 
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can memorize and use without taking the terminal out of his trouser pocket. 

Figure 10 illustrates associations 100 of (reachability) profiles 101, 
caller groups 102 and redirection settings 103. The first association 1001 as- 
sociates profile "Work" and caller group "Family" with redirection setting "Of- 

5 ficeFirst". This means that whenever profile "Work" is Bill's current profile, calls 
from members of the "Family" group are processed according to redirection 
setting "OfficeFirst". This redirection setting was described as record 901 in 
Figure 9. In the example shown in Figure 10, there are six associations, 
namely 1001 to 1006, for the profile 'Work". Associations 1001 to 1003 specify 

10 that calls from members of the "Family", "Colleague" and "Secretary" groups 
are processed according to redirection setting "OfficeFirst", while calls from 
"Friends", "Others" and "Unknown" groups are processed according to redirec- 
tion setting "Secretary", which means that the call is routed to Bill's secretary. 

The example shown in Figure 10 does not have an association for 

15 each combination of profile, caller group and redirection setting. This is be- 
cause this example makes use of the (optional) default redirection setting field 
83 shown in Figure 8. For instance, the profile "Abroad" has a default redirec- 
tion setting of "MobileFirst" which is used unless an overriding association for 
some caller groups have been specified. Figure 10 shows an association 1031 

20 of profile "Abroad", caller group "Unknown" and redirection setting "VoiceMail". 
This means that when Bill is abroad, he does not wish to take calls from un- 
known callers because he would have to pay for those calls. Accordingly, calls 
from unknown callers are routed to voice mail. 

An advantage of the profiles and redirection settings is that it is very 

25 easy for users to change their reachability settings, even when there are multi- 
ple caller groups, all requiring different reachability settings. Because the pro- 
files are separated from the redirection settings, the profiles may be very sim- 
ple and, in a simple embodiment, only a profile name or indicator is necessary. 

The invention is preferably implemented by co-operation between 

30 the terminal and an element (mode server) in the fixed network. This co- 
operation is further improved by setting the alert of the terminal automatically 
to silent/vibrating if the current profile of the B party indicates silent communi- 
cation. This way, the user does not have to select a profile that indicates silent 
communication and silence the terminal's alert separately. 

35 Preferably, the profiles comprise presence information and/or in- 

structions which is/are returned to the A party. For example, the presence in- 
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formation/instructions may indicate "I am in a meeting, please dial 1 if you wish 
to leave a message, or, dial 2 if you have urgent business; I can reply by chat- 
ting". 

Figure 1 1 is a flow chart illustrating the operation of a reachability 

5 server. Figure 11 shows a preferred implementation of steps 3-14 and 3-16 
shown in Figure 3. In step 1101, the reachability server receives and stores in 
memory Bill's caller lists 70 (of which only field 72 is essential) and caller 
groups 73 (see Figure 7), his profiles 80 (see Figure 8), redirection settings 90 
(see Figure 9) and associations 100 of the above three types of data (see Fig- 

10 ure 10). Step 1101 can take place in one go or in a distributed manner. In 
other words, Bill can indicate the settings 70, 73, 80, 90 and 100 during one 
session, or he may update previous settings. 

Dashed lines 1102 and 1105 denote occasions in which the reach- 
ability server waits for more actions from Bill or a caller, respectively. In step 

15 1103, Bill's reachability settings change and he updates his current profile in 
the reachability server. In other words, he indicates the current one of the pre- 
existing profiles stored in the reachability server. For instance, if Bill is about to 
enter an airplane, he selects "Flight" as his current profile. 

The remaining steps 1111 to 1118 relate to processing of one call. 

20 In step 1111, the reachability server detects a call to Bill from an A user. In 
step 1112, the reachability server retrieves Bill's current profile. In step 1113, 
the reachability server determines the A user's identity. For example, the A 
user can be identified by means of a Calling Line Indicator (CLI). In step 1114, 
the reachability server determines the A user's caller group, that is, the caller 

25 group 73 corresponding to the A user's identity 71 . In step 1115, the reachabil- 
ity server attempts to retrieve the redirection settings record 100 corresponding 
to the A user's caller group 73 and Bill's current profile 80. In step 1116, it is 
checked if such a redirection settings record could be determined, which 
means that there was an association corresponding to the A user's identity and 

30 Bill's current profile. If yes, the process continues to step 1 1 1 8 in which the call 
is processed according to the redirection settings. 

According to a preferred embodiment, if the check in step 1116 
failed, the process continues to step 11 17 in which it is checked if Bill's current 
profile indicates a default redirection setting. For instance, each of the profiles 

35 'Theatre", "Flight" and "Abroad" in Figure 8 do indicate a default redirection 
setting. If Bill's current profile indicates a default redirection setting, the proc- 
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ess again continues to step 1118 in which the call is processed according to 
the (default) redirection settings. 

If checks 1116 and 1117 both fail, the process continues to step 
1 1 19 in which the call is processed normally (no redirection or mode change). 

5 An advantage of the profiles and redirection settings as shown in 

Figures 7 to 1 1 is that the terminal user has to send the reachability server only 
one piece of information, namely an indicator of the current profile, whenever 
the reachability conditions change. The caller groups, profiles and redirec- 
tion/call mode settings are pre-stored and are changed much less often. Be- 

10 cause the caller groups, profiles and redirection/call mode settings are pre- 
stored at the reachability server (or are otherwise accessible by it), call proc- 
essing is much more flexible than in a system which only supports a single re- 
direction setting to all callers. 

Further enhancements to the mode/reachability server 

15 Preferably, the mode server MS and the reachability server RS (or 

equivalent functions in other network elements) support as many as possible 
from the following redirections and mode changes: 

1 . redirection to another telephone; 

2. redirection to voice mail; 

20 3. timed redirection to another telephone/voice mail (e.g. five sec- 

onds to office phone, 5 seconds to mobile phone, then to voice 
mail; 

4. sending the caller a data message, such as a short message or 
an MMS (Multimedia Messaging Specification) message, or a 

25 partial or whole web page; 

5. sending the caller a network address, such as a URL, preferably 
formatted as a link, wherein the network address contains more 
detailed information; 

6. conversion of incoming and/or outgoing call to chat or limited 
30 chat (e.g. 2-key chat); 

7. conversion of incoming and/or outgoing voice to text or vice 
versa; 

8. providing additional services (music, video, games...) during 
waiting; 

35 9. personalized voice answering in the answer service (network- 
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based or terminal based); that is, the voice information depends 
on A's caller group and B's current profile; 
Option 6 is implemented without text-to-speech or speech-to-text 
conversion. That is, if B can only chat but not talk, then a chat connection is 
5 established in at least one direction. For instance, A can talk to B but B will 
type his responses. Alternatively, both parties can resort to chatting. Option 7 
requires text-to-speech or speech-to-text conversion. For instance, A can talk 
and B's typed responses are converted to speech. 

The invention is useful if one or both parties of a call cannot speak 
10 on a telephone, regardless of why such two-way speaking is impossible. Two- 
way speaking may be prohibited by law or etiquette, or one or both parties may 
be physically handicapped. It is readily apparent to a person skilled in the art 
that, as the technology advances, the inventive concept can be implemented in 
various ways. The invention and its embodiments are not limited to the exam- 
15 pies described above but may vary within the scope of the claims. 

Acronyms: 

CLI: Calling Line Indicator 

GSM: Global System for Mobile Communication 

MSISDN: Mobile Subscriber Integrated Services Data Network 
20 PSTN: Public Switched Telephone Network 

SIM: Subscriber Identity Module 

TCP/IP: Transport Control Protocol/Internet Protocol 

UMTS: Universal Mobile Telecommunications System 

URL: Uniform Resource Locator 
25 VoIP: Voice over Internet Protocol 



